1. Field
Various features pertain to securing information entered using an input device, and more particularly, to protecting access to information entered via touchscreen input devices.
2. Background
Many electronic devices are reducing the use of dedicated input devices in favor of multi-use devices, such as touchscreens, which can serve as both input and output devices. This often permits the electronic devices to be smaller in size and/or allow for increased display size. Touchscreens also offer greater flexibility since they permit the appearance and/or configuration of a keypad image (i.e., input device) displayed on the touchscreen to be modified.
With a touchscreen driver it is necessary to display the input device image on the screen that allows the user to know where on the screen to touch for a particular input symbol (e.g. the letter “a”). Contrary to a traditional keyboard or keypad, implementing a touchscreen keyboard or keypad involves two components, an input (the touchscreen) and an output (the display). When implementing a keyboard/keypad, the touchscreen operates as an input device. However, in order to provide the user with feedback about which key has been pressed, some kind of visual feedback is provided. For example, the pressed key's value may be displayed above the touch point, or the shading of the key may change to give the impression that it has been depressed. This type of keyboard/keypad, and any accompanying visual feedback, is often controlled by the high level operating system (HLOS), such as Android® and iOS®. Thus, the HLOS controls the user interface (UI) and may receive events from the touchscreen driver.
However, the HLOS may be susceptible to attacks or hacking, which allow unauthorized access to the information entered on the touchscreen. In a system (e.g., processor) that provides a trusted execution environment (TEE) it may be necessary to have the input pass directly from the hardware to the TEE. This is achieved by transferring control of the input device from the HLOS to the TEE, such that the HLOS has no access to the inputs entered by the user, and the inputs instead are only accessible to the TEE. In the case of a typical physical keyboard/keypad this is fairly straightforward since the only visual feedback the user typically sees is the appearance of a concealment character (e.g., “*”) in the display input area, and the physical, tactile feedback of the keyboard/keypad that indicates that a key has been depressed.
However, if the input device is a touchscreen the situation is more complicated since, even if an application operating at the HLOS displays a keyboard/keypad, the driver for the touchscreen is executed in the TEE. Also, the only output a touchscreen typically provides is where the display is being touched (e.g., a coordinate or screen location). (Depending on the complexity of the touchscreen driver, some input gestures such as swiping motions may also be provided.) The mapping of the screen location coordinates to the corresponding actions are typically handled by the HLOS which may control the display and know to what actions and/or keys a particular screen coordinate corresponds to. Even if the touchscreen driver executed on the TEE were to have a mapping between the keys displayed on the screen by the HLOS, such architecture may still not provide secure input because some HLOSs, such as Android®, allow the user to replace the default touchscreen keyboard/keypad with another keyboard/keypad. In such cases the TEE may not know the keyboard/keypad mapping without some mapping information being provided by the HLOS. Since the HLOS cannot be considered secure, the TEE cannot rely on such mapping information provided by the HLOS.
Therefore, there is a need for a secure way to implement an input device using a touchscreen.